Embedded systems, such as diskless workstations can incorporate various types of utility software for booting over a network. As network and processing tasks are divided among different processing components on a CPU (central processing unit) motherboard, different routines are often configured to perform different tasks related to network access and booting. For example, a Pre-Boot Execution Environment (PXE), such as that defined by the Unified Extensible Firmware Interface (UEFI) specification (http://www.uefi*org) has been developed to provide firmware utilities and CPU BIOS (Basic Input/Output System) functionality. Other programs, such as the Intel® Active Management Technology (AMT) (http://intel*com/technology/manage/iamt/) have been developed to provide improved networking capabilities (note the previous URL addresses have substituted a “*” in place of a period). One issue related to the division of tasks between different bodies of code is that each body of code typically does not provide the services provided by the other body of code, and they may not collaborate sufficiently well to speed the boot process in many network implementations.
In general, PXE code (and variations thereof) represents an in-band BIOS (Basic Input/Output System) firmware regime that provides a pre-boot execution environment for a host CPU. As such, it is a relatively minimal body of code that typically does not have sufficient networking capabilities until relatively late in the boot process. Furthermore, the PXE code usually does not have enough flash space to support all network authentication protocols. The Intel® AMT firmware, in contrast, typically carries a full network stack to support various web services. These network protocols include TCP/IP (Transmission Control Protocol/Internet Protocol), HTTP (Hypertext Transport Protocol), and SSL/TLS (Secure Sockets Layer/Transport Layer Security). At present, when implemented on the same computer, these two execution domains collaborate to a limited extent during the pre-boot stage. After pre-boot, however, the two execution regimes are largely separate and do not collaborate with one another.
In a typical implementation, the Intel® AMT code is executed on a co-processor platform within the host CPU system. For an AMT-only boot scenario, such as IDE-Redirection (IDE-R) for Integrated Drive Electronics (IDE) devices, the AMT program is constrained by the network throughput of the out-of-band microcontroller subsystem.
The PXE (BIOS) boot is generally faster since it runs on the in-band CPU and is advantaged by the ever-increasing speed of current microprocessors. However, the BIOS PXE boot is constrained by the capacity; of flash memory and typically cannot bear the cost of implementing the certain stacks, such as TLS/SSL. In many present systems, the PXE process occurs late in the Power-On/Self-Test (POST) process since it requires main memory to be initialized and tested, the I/O bus to be resource balanced, and the network interface controller driver to be installed in BIOS/firmware. There may also be a required timeout the protocol to implement a server name request. With regard to authentication, current PXE authentication schemes are weak because it is difficult to carry security mechanisms, such as a full SSL/TLS stack in BIOS.